An Input/Output Buffer Information Specification or “IBIS” is a specification of a method for integrated circuit vendors to provide information about the input/output buffers of their product to their prospective customers without revealing the intellectual property of their implementation and without requiring proprietary encryption keys. The specification may include two separate types of models, “traditional IBIS” and “IBIS-AMI.” The traditional model is generated in text format and consists of a number of tables that captures current vs. voltage (IV) and voltage vs. time (Vt) characteristics of the buffer, as well as the values of certain parasitic components. It is a standard data exchange format for exchanging modeling information among semiconductor device suppliers, simulation software suppliers, and end users.
Traditional IBIS models are generally used instead of SPICE models to perform various board level signal integrity (SI) simulations and timing analyses. IBIS models could be used to verify signal integrity requirements, especially for high-speed products. These IBIS models are often generated using a SPICE netlist
As discussed above, the IBIS model may capture the behavior of the IO-buffer as tabular data such as rise/fall waveforms (V/T data) and V/I curves. The tabular data is obtained by doing transient (V/T) and dc-sweep simulations (V/I) using standard stimulus. However, identifying the nodes for application of stimulus by reading textual netlists is painful. There are often a large number of simulations and trials required to ensure all of the dependencies for models are resolved. This involves huge amounts of manual preparation of Spice netlists for each simulation run.
Moreover, existing approaches require the use of templates that are difficult to understand as they use IBIS keywords that do not make much sense to a designer or model maker. The user needs to open the Spice netlists and go through sub-circuit nodes and mention the relevant nodes in templates. Multiple templates have to be created for each of the variants of the IO-model and each of the model-types. By way of example, a typical IO could have 30 strength variants, 3 speed variants each and 2 model-types, leading to 180 combinations.